A widget (also commonly referred to as a web widget) is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. Widgets are client-side applications that may be authored using web standards and packaged for distribution. They may be downloaded and installed on client machines. A widget may run as a stand-alone application (meaning it can run outside of a Web browser). Widgets are downloadable applications commonly written using HTML, JavaScript, and CSS and utilize web technologies and standards.
The runtime environment in which a widget is run is referred to as a widget user agent or the Web Runtime System (WRT). The WRT is responsible for installation/de-installation of widgets, and to provide functionality for invocation and configuration of the widgets. The WRT is also responsible for the execution of widgets. For example, Web widgets are typically written in JavaScript, which is an independent language. The WRT contains a software module, known as a JavaScript engine, to interpret the widget's JavaScript code and perform the execution.
FIG. 1 illustrates an example of a simplified high level architecture diagram of a WRT based on the Limo™ platform (i.e., Linux™ based mobile phone platforms). In this example, at the User Interface (UI) layer, the widgets may perform functions such as providing weather information, a clock, or a photo viewer. There is a Web Runtime UI. At the engine layer, there is a widget engine and a widget manager. At the core layer, there is a Webkit. The Webkit is a library used in Web engines. The WRT is the collection of all components, over and above the Web Engine at the core layer, needed to support installed widgets.
A widget package is a package, conforming to specific standards (e.g. See “Widgets: Packaging and Configuration specification”, W3C Proposed Recommendations, 11 Aug. 2011, published by W3C, the World Wide Web Consortium), containing various files (including configuration documents, icons, digital signatures, etc.) that constitute the implementation of a widget. A widget package contains metadata, which will be referred to in this patent application as the manifest file, for the associated widget. A manifest file specifies a multitude of things of which include the access restrictions for a widget. The access restrictions are used by the WRT to control accesses by a widget to device capabilities, network resources, file system, etc.
There are several different standards bodies that are setting slightly different specifications and standardizations for widgets and JavaScript APIs for widgets. These bodies setting specification for widgets include: W3C, WAC, JIL, BONDI, and Opera among others. As a result, there are different types of widgets and widget runtime systems. Although, the details of the specifications (e.g., how to specify access rights and the granularity of permissions) differ, the general security models and access control enforcement principles of these widget systems are very similar.
The access control enforcements in current WRT implementations are handled by the user-space code of the WRT in the same process that runs the widget itself. For example, these controls and enforcements are handled in Web Engine code as shown in FIG. 2 which shows an overall high level architecture of a BONDI widget implementation having access control features at the Web Engine level.
Referring to FIG. 3, the inventors of the present patent application have recognized that a security vulnerability in conventional WRT arises because the access control enforcement in current WRT implementations is handled by the user-space code of WRT, which is in the same process that runs the widget itself. For example, these controls and enforcements are handled in the Web Engine (e.g. WebKit) code. As illustrated in FIG. 3, a benign process with a legitimate access flow will go through security checks. However, a compromised process has a corrupted access flow that can result in bypassing the mentioned security checks.
Security controls in conventional WRTs are inherently vulnerable and can be bypassed via threats such as address space corruption and code injection. For example, a web engine may contain a bug that allows remote attackers or malicious widgets to inject and run arbitrary code or change the legitimate control flow in that web engine. As a result, an attacker/widget can bypass the security checks and access the restricted resources as illustrated in the below figure.
As an illustrative example, Safari™, the popular web browser has several vulnerability types that can result in bypassing security checks. Safari™ is based on the same web engine, called WebKit, which is used in many mobile platforms including iPhone™ and Android™ platforms. These vulnerabilities include an execute code vulnerability, an overflow vulnerability, and a memory corruption vulnerability. Safari™ is based on the same WebKit web engine used in many mobile platforms. Thus, there are significant security concerns associated with conventional WRT security controls.